%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
%                       Legal Notice                            %
%                                                               %
% This document is copyright (C) Olaf Kirch, okir@monad.swb.de  %
%                                                               %
% For copying conditions, please refer to the file COPYING.	%
%                                                               %
% The author is not liable for any damages, direct or indirect, %
% resulting from the use of information provided in this        %
% document.                                                     %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% When viewing this document with vi on an 80-columns screen,   %
% do a ':se nonumber' first.                                    %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
%               S T A R T   O F   C H A P T E R                 %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Configuring the Networking Hardware}
\label{hardware}
\index{configuring!network hardware|(}
\index{hardware!networking|(}


\section{Devices, Drivers, and all that}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{hardware.drivers}
\index{network!devices}
\index{interface}

Up to now, we've been talking quite a bit about network interfaces and
general TCP/IP issues, but didn't really cover exactly \emph{what}
happens when ``the networking code'' in the kernel accesses a piece of
hardware.  For this, we have to talk a little about the concept of
interfaces and drivers.


First, of course, there's the hardware itself, for example an Ethernet
board: this is a slice of Epoxy, cluttered with lots of tiny chips
with silly numbers on them, sitting in a slot of your PC.  This is
what we generally call a device.


For you to be able to use the Ethernet board, special functions have
to be present in your \linux{} kernel that understand the particular
way this device is accessed. These are the so-called device drivers.
For example, \linux{} has device drivers for several brands of
Ethernet boards that are very similar in function.  They are known as
the ``Becker Series Drivers'', named after their author, Donald
Becker. A different example is the D-Link driver that handles a D-Link
pocket adaptor attached to a parallel port.


But, what do we mean when we say a driver ``handles'' a device?  Let's
go back to that Ethernet board we examined above. The driver has to be
able to communicate with the peripheral's on-board logic somehow: it
has to send commands and data to the board, while the board should
deliver any data received to the driver.


%%%%%%%% Put the picture here, so it's in a central place
\iftex
 \begin{figure}[tbp]
  \ifps
   \begin{center}
    \mbox{ \epsffile{figures/iface.epsf} }
   \end{center}
  \else
   \begin{center}
    \input{iface.eepic}
   \end{center}
  \fi
  \caption{
   \label{hardware.fig.drivers}
   The relationship between drivers, interfaces, and the
   hardware.
  }
 \end{figure}
\else
\fi


In PCs, this communication takes place through an area of I/O~memory
that is mapped to on-board registers and the like.  All commands and
data the kernel sends to the board have to go through these registers.
I/O memory is generally described by giving its starting or \emph{base
address}. Typical base addresses for Ethernet boards are \addr{0x300},
or \addr{0x360}.


Usually, you don't have to worry about any hardware issues such as the
base address, because the kernel makes an attempt at boot time to
detect a board's location. This is called autoprobing, which means
that the kernel reads several memory locations and compares the data
read with what it should see if a certain Ethernet board was
installed. However, there may be Ethernet boards it cannot detect
automatically; this is sometimes the case with cheap Ethernet cards
that are not-quite clones of standard boards from other manufacturers.
Also, the kernel will attempt to detect only one Ethernet device when
booting. If you're using more than one board, you have to tell the
kernel about this board explicitly.


\index{IRQ}
Another such parameter that you might have to tell the kernel about is
the interrupt request channel.  Hardware components usually interrupt
the kernel when they need care taken of them, e.g.  when data has
arrived, or a special condition occurs. In a PC, interrupts may occur on
one of 15 interrupt channels numbered 0, 1, and 3 through 15. The
interrupt number assigned to a hardware component is called its
\emph{interrupt request number}, or IRQ.\footnote{
 IRQs 2 and 9 are the same because the PC has two cascaded interrupt
 processors with eight IRQs each; the secondary processor is connected
 to IRQ~2 of the primary one.
}


\index{IP!interface}
\index{interface}
As described in chapter~\ref{tcpip}, the kernel accesses a device
through a so-called interface.  Interfaces offer an abstract set of
functions that is the same across all types of hardware, such as
sending or receiving a datagram.


Interfaces are identified by means of names. These are names defined
internally in the kernel, and are not device files in the \file{/dev}
directory.  Typical names are \file{eth0}, \file{eth1}, etc, for
Ethernet interfaces. The assignment of interfaces to devices usually
depends on the order in which devices are configured; for instance the
first Ethernet board installed will become \file{eth0}, the next will
be \file{eth1}, and so on. One exception from this rule are SLIP
interfaces, which are assigned dynamically; that is, whenever a SLIP
connection is established, an interface is assigned to the serial
port.


The picture given in figure~\ref{hardware.fig.drivers} tries to show
the relationship between the hardware, device drivers and interfaces.


When booting, the kernel displays what devices it detects, and what
interfaces it installs. The following is an excerpt of a typical
boot screen:

%%%%%%%%% ignore this %%%%%%%%%%%%
% Console: colour EGA+ 80x25, 8 virtual consoles
% Serial driver version 3.99a with no serial options enabled
% tty00 at 0x03f8 (irq = 4) is a 16450
% tty01 at 0x02f8 (irq = 3) is a 16550
% lp_init: lp1 exists, using polling driver
% Calibrating delay loop.. ok - 25.04 BogoMips
% Configuring Adaptec at IO:330, IRQ 11, DMA priority 5
% scsi0 : Adaptec 1542
% scsi : 1 hosts.
%   Vendor: CDC       Model: 94171-9           Rev: 6580
%   Type:   Direct-Access                      ANSI SCSI revision: 01 CCS
% Detected scsi disk sda at scsi0, id 0, lun 0
% scsi : detected 1 SCSI disk total.
% Memory: 7080k/8192k available (540k kernel code, 384k reserved, 188k data)

\begin{tscreen}
\begin{verbatim}
 .
 .
This processor honours the WP bit even when in supervisor mode. Good.
Floppy drive(s): fd0 is 1.44M
Swansea University Computer Society NET3.010
IP Protocols: ICMP, UDP, TCP
PPP: version 0.2.1 (4 channels) OPTIMIZE_FLAGS
TCP compression code copyright 1989 Regents of the University of California
PPP line discipline registered.
SLIP: version 0.7.5 (4 channels)
CSLIP: code copyright 1989 Regents of the University of California
dl0: D-Link DE-600 pocket adapter, Ethernet Address: 00:80:C8:71:76:95
Checking 386/387 coupling... Ok, fpu using exception 16 error reporting.
Linux version 1.1.11 (okir@monad) #3 Sat May 7 14:57:18 MET DST 1994
\end{verbatim}
\end{tscreen}


This shows that the kernel has been compiled with TCP/IP enabled, and
drivers for SLIP, CSLIP, and PPP included.  The third line from below says
that a D-Link pocket adaptor was detected, and installed as interface
\file{dl0}.  If you have a different type of Ethernet card, the kernel will
usually print a line starting with \file{eth0}, followed by the type of
card detected.  If you have an Ethernet card installed but don't see any
such message, this means that the kernel is unable to detect your board
properly.  This is dealt with in a later section.


\section{Kernel Configuration}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Most \linux{} distributions come along with boot disks that
work for all common types of PC hardware.  This means that the kernel
on those disks has all sorts of drivers configured in that you will
never need, but which waste precious system memory because parts
of the kernel cannot be swapped out. Therefore, you will generally
roll your own kernel, including only those drivers you actually need or
want.


When running a \linux{} system, you should be familiar with building a
kernel. The basics of this are explained in Matt Welsh's ``Installation and
Getting Started'' Guide, which is also part of the \linux{} Documentation
Project's series.  In this section, we will therefore discuss only those
configuration options that affect networking.


When running \term{make config}, you will first be asked general
configurations, for instance whether you want kernel math emulation or
not, etc. One of these asks you whether you want TCP/IP networking
support. You must answer this with \term{y} to get a kernel capable of
networking.


\subsection{Kernel Options in \linux{} 1.0 and Higher}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{configuring!kernel}
\index{network!kernel options}
\index{kernel network configuration}
\index{configuring!Ethernet}
\index{configuring!SLIP}
\index{configuring!PLIP}
\index{configuring!PPP}

After the general option part is complete, the configuration will go
on to ask you for various features such as SCSI drivers, etc. The
subsequent list questions deal with networking support. The exact set
of configuration options is in constant flux because of the ongoing
development. A typical list of options offered by most kernel versions
around 1.0 and 1.1 looks like this (comments are given in italics):


\def\y{\term{y}}

\begin{tscreen}
\begin{verbatim}
*
* Network device support
*
Network device support? (CONFIG_ETHERCARDS) [y]
\end{verbatim}
\end{tscreen}

	Despite the macro name displayed in brackets, you must
	answer this question with \y{} if you want to use \emph{any}
	type of networking devices, regardless of whether this is
	Ethernet, SLIP, or PPP.  When answering this question with
	\y{}, support for Ethernet-type devices is enabled
	automatically.  Support for other types of network drivers
	must be enabled separately:


\begin{tscreen}
\begin{verbatim}
SLIP (serial line) support? (CONFIG_SLIP) [y]
 SLIP compressed headers (SL_COMPRESSED) [y]
PPP (point-to-point) support (CONFIG_PPP) [y]
PLIP (parallel port) support (CONFIG_PLIP) [n]
\end{verbatim}
\end{tscreen}

	These questions concern the various link layer protocols
	supported by \linux{}.  SLIP allows you to transport IP
	datagrams across serial lines.  The compressed header option
	provides support for CSLIP, a technique that compresses
	TCP/IP headers to as little as three bytes.  Note that this
	kernel option does not turn on CSLIP automatically, it
	merely provides the necessary kernel functions for it.

	PPP is another protocol to send network traffic across
	serial lines.  It is much more flexible than SLIP, and is
	not limited to IP, but will also support IPX once it is
	implemented.  As PPP support has been completed only lately,
	this option may not be present in your kernel.


	PLIP provides for a way to send IP datagrams across a
	parallel port connection.  It is mostly used to communicate
	with PCs running DOS.


	The following questions deal with Ethernet boards from
	various vendors.  As more drivers are being developed,
	you are likely to see questions added to this section.
	If you want to build a kernel you can use on a number of
	different machines, you can enable more than one driver.


\begin{tscreen}
\begin{verbatim}
NE2000/NE1000 support (CONFIG_NE2000) [y]
WD80*3 support (CONFIG_WD80x3) [n]
SMC Ultra support (CONFIG_ULTRA) [n]
3c501 support (CONFIG_EL1) [n]
3c503 support (CONFIG_EL2) [n]
3c509/3c579 support (CONFIG_EL3) [n]
HP PCLAN support (CONFIG_HPLAN) [n]
AT1500 and NE2100 (LANCE and PCnet-ISA) support (CONFIG_LANCE) [n]
AT1700 support (CONFIG_AT1700) [n]
DEPCA support (CONFIG_DEPCA) [n]
D-Link DE600 pocket adaptor support (CONFIG_DE600) [y]
AT-LAN-TEC/RealTek pocket adaptor support (CONFIG_ATP) [n]
*
* CD-ROM drivers
*
...
\end{verbatim}
\end{tscreen}


	\index{configuring!NFS}
	Finally, in the filesystem section, the configuration script
	will ask you whether you want support for NFS, the
	networking filesystem.  NFS lets you export filesystems
	to several hosts, which makes the files appear as if they
	were on an ordinary hard disk attached to the host.


\begin{tscreen}
\begin{verbatim}
NFS filesystem support (CONFIG_NFS_FS) [y]
\end{verbatim}
\end{tscreen}


\subsection{Kernel Options in \linux{} 1.1.14 and Higher}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Starting with \linux{} 1.1.14, which added alpha support for IPX,
the configuration procedure changed slightly. The general options section
now asks whether you want networking support in general. It is
immediately followed by a couple of question on miscellaneous
networking options.

\begin{tscreen}
\begin{verbatim}
*
* Networking options
*
TCP/IP networking (CONFIG_INET) [y]
\end{verbatim}
\end{tscreen}

	To use TCP/IP networking, you must answer this question with
	\term{y}. If you answer with \term{n}, however, you will still
	be able to compile the kernel with IPX support.

\begin{tscreen}
\begin{verbatim}
IP forwarding/gatewaying (CONFIG_IP_FORWARD) [n]
\end{verbatim}
\end{tscreen}

	\index{forwarding!IP}
	\index{IP!forwarding}
	You have to enable this option if your system acts as a
	gateway between two Ethernets, or between and Ethernet and a
	SLIP link, etc.  Although it doesn't hurt to enable this by
	default, you may want to disable this to configure a host as a
	so-called firewall. Firewalls are hosts that are connected to
	two or more networks, but don't route traffic between them.
	They are commonly used to provide users from a company network
	with Internet access at a minimal risk to the internal
	network. Users will be allowed to log into the firewall and
	use Internet services, but the company's machines will be
	protected from outside attacks because any incoming
	connections can't cross the firewall.


\begin{tscreen}
\begin{verbatim}
*
* (it is safe to leave these untouched)
*
PC/TCP compatibility mode (CONFIG_INET_PCTCP) [n]
\end{verbatim}
\end{tscreen}

	\index{PC/TCP compatibility}
	This option works around an incompatibility with some versions
	of PC/TCP, a commercial TCP/IP implementation for DOS-based
	PCs. If you enable this option, you will still be able to
	communicate with normal \unix{} machines, but performance may
	be hurt over slow links.


\begin{tscreen}
\begin{verbatim}
Reverse ARP (CONFIG_INET_RARP) [n]
\end{verbatim}
\end{tscreen}

	\index{RARP}
	This function enables RARP, the Reverse Address Resolution
	Protocol. RARP is used by diskless clients and X~terminals to
	inquire their IP~address when booting.  You should enable RARP
	only when you plan to serve this sort of clients.  The latest
	package of network utilities (\file{net-0.32d}) contains a small
	utility named \prog{rarp} that allows you to add systems to the
	RARP cache.


\begin{tscreen}
\begin{verbatim}
Assume subnets are local (CONFIG_INET_SNARL) [y]
\end{verbatim}
\end{tscreen}

	\index{IP!routing}
	\index{IP!subnet}
	\index{subnet (IP)}
	\index{Subnets Are Local@`Subnets Are Local' Policy}
	\index{SNARL|see{`Subnets Are Local' Policy}}
	When sending data over TCP, the kernel has to break up the
	stream into several packets before giving it to IP. For hosts
	that can be reached over a local network such as an Ethernet,
	larger packets will be used than for hosts where data has to
	go through long-distance links.\footnote{
	  This is to avoid fragmentation by links that have a very small
	  maximum packet size.
	} If you don't enable \keyword{SNARL}, the kernel will assume
	only those networks are local that it actually has an interface
	to. However, if you look at the class B network at Groucho
	Marx University, the whole class B network is local, but most
	hosts interface to only one or two subnets. If you enable
	\keyword{SNARL}, the kernel will assume \emph{all} subnets
	are local and use large packets when talking to all hosts on
	campus.

	If you do want to use smaller packet sizes for data sent to
	specific hosts (because, for instance, the data goes through
	a SLIP link), you can do so using the \prog{mtu} option of
	\prog{route}, which is briefly discussed at the end of this
	chapter.



\begin{tscreen}
\begin{verbatim}
Disable NAGLE algorithm (normally enabled) (CONFIG_TCP_NAGLE_OFF) [n]
\end{verbatim}
\end{tscreen}


	\index{Nagle's algorithm}
	\index{avoid tinygrams}
	\index{IP!tinygrams}
	\index{tinygrams}
	Nagle's rule is a heuristic to avoid sending particularly
	small IP packets, also called tinygrams. Tinygrams are usually
	created by interactive networking tools that transmit single
	keystrokes, such as \prog{telnet} or \prog{rsh}. Tinygrams can
	become particularly wasteful on low-bandwidth links like SLIP.
	The Nagle algorithm attempts to avoid them by holding back
	transmission of TCP data briefly under some circumstances. You
	might only want to disable Nalge's algorithm if you have
	severe problems with packets getting dropped.



\begin{tscreen}
\begin{verbatim}
The IPX protocol (CONFIG_IPX) [n]
\end{verbatim}
\end{tscreen}


	\index{configuring!IPX}
	\index{protocol!IPX}
	\index{IPX}
	This enables support for IPX, the transport protocol used by
	Novell Networking. It is still under development, and isn't
	really useful yet. One benefit of this will be that you can
	exchange data with IPX-based DOS utilities one day, and route
	traffic between your Novell-based networks through a PPP link.
	Support for the high-level protocols of Novell
	networking is however not in sight, as the specifications for
	these are available only at horrendous cost and under a
	non-disclosure agreement.


	Starting in the 1.1.16 kernel, \linux{} supports another
	driver type, the dummy driver.  The following question appears
	toward the start of the device driver section.

\begin{tscreen}
\begin{verbatim}
Dummy net driver support (CONFIG_DUMMY) [y]
\end{verbatim}
\end{tscreen}

	The dummy driver doesn't really do much, but is quite useful 
	on standalone or SLIP hosts.  It is basically a masqueraded
	loopback interface. The reason to have this sort of interface
	is that on hosts that do SLIP but have no Ethernet, you want to
	have an interface that bears your IP address all the time.
	This is discussed in a little more detail in
	section~\ref{iface.interface.dummy} in chapter~\ref{iface}.




\section{A Tour of \linux{} Network Devices}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
The \linux{} kernel supports a number of hardware drivers for various
types of equipment. This section gives a short overview of the driver
families available, and the interface names used for them.


\index{interface}
There are a number of standard names for interfaces in \linux, which
are listed below. Most drivers support more than one interface, in
which case the interfaces are numbered, as in \file{eth0},
\file{eth1}, etc.


\begin{dispitems}
\ditem[\file{lo}]
        \index{interface!loopback}
        The local loopback interface. It is used for testing purposes,
        as well as a couple of network applications. It works like a
        closed circuit in that any datagram written to it will be
        immediately returned to the host's networking layer.  There's
        always one loopback device present in the kernel, and there's
        little sense in having fewer or more.

\ditem[\file{eth\var{n}}]
        \index{interface!Ethernet}
        The \var{n}-th Ethernet card. This is the generic interface name
        for most Ethernet boards.

\ditem[\file{dl\var{n}}]
        \index{interface!D-Link DE-600}
	These interfaces access a D-Link DE-600 pocket adapter, another
	Ethernet device. It is a little special in that the DE-600
	is driven through a parallel port.

\ditem[\file{sl\var{n}}]
        \index{interface!SLIP}
        The \var{n}-th SLIP interface. SLIP interfaces are associated
        with serial lines in the order in which they are allocated for
        SLIP; i.e., the first serial line being configured for SLIP
        becomes \file{sl0}, etc. The kernel supports up to four SLIP
        interfaces.

\ditem[\file{ppp\var{n}}]
        \index{interface!PPP}
	The \var{n}-th PPP interface. Just like SLIP interfaces, a PPP
	interface is associated with a serial line once it is converted
	to PPP mode. At the moment, up to four interfaces are supported.

\ditem[\file{plip\var{n}}]
        \index{interface!PLIP}
        The \var{n}-th PLIP interface. PLIP transports IP datagrams
        over parallel lines. Up to three PLIP interfaces are supported.
        They are allocated by the PLIP driver at system boot time, and
        are mapped onto parallel ports.

\end{dispitems}


\index{protocol!AX.25}
\index{protocol!IPX}
\index{driver!ISDN}
\index{AX.25}
\index{ISDN}
For other interface drivers that may be added in the future, like ISDN,
or AX.25, other names will be introduced. Drivers for IPX (Novell's
networking protocol), and AX.25 (used by ham radio amateurs) are under
development, but are at alpha stage still.


During the following sections, we will discuss the details of using
the drivers described above.



\section{Ethernet Installation}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{hardware.drivers.ethernet}
\index{configuring!Ethernet|(}
\index{Ethernet!Becker drivers}
\index{Ethernet!installation}
\index{Becker, Donald}
\index{driver!Ethernet}
\index{Ekwall, Bjorn@Ekwall, Bj\o{}rn}
\index{Davies, David C.}
\index{Ethernet!through parallel port}
\index{parallel port!Ethernet}
\index{D-Link pocket adaptor}
\index{driver!Ethernet}
\index{driver!D-Link}

The current \linux{} network code supports various brands of Ethernet
cards. Most drivers were written by Donald Becker
(\email{becker@cesdis.gsfc.nasa.gov}), who authored a family of
drivers for cards based on the National Semiconductor~8390 chip; these
have become known as the Becker Series Drivers.  There are also
drivers for a couple of products from D-Link, among them the D-Link
pocket adaptor that allows you to access an Ethernet through a
parallel port. The driver for this was written by Bj\o{}rn Ekwall
(\email{bj0rn@blox.se}). The DEPCA driver was written by David
C.~Davies (\email{davies@wanton.lkg.dec.com}).


\subsection{Ethernet Cabling}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{Ethernet!cabling}
\index{Ethernet!thin}
\index{BNC connector}
\index{thinnet}

If you're installing an Ethernet for the first time in your life, a few
words about the cabling may be in order here. Ethernet is very picky
about proper cabling. The cable must be terminated on both ends with a
50~Ohm resistor, and you must not have any branches (i.e. three cables
connected in a star-shape). If you are using a thin coax cable with
T-shaped BNC junctions, these junctions must be twisted on the board's
connector directly; you should not insert a cable segment.


If you connect to a thicknet installation, you have to attach your
host through a transceiver (sometimes called Ethernet Attachment
Unit).  You can plug the transceiver into the 15-pin AUI port on your
board directly, but may also use a shielded cable.


\subsection{Supported Boards}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{HOWTO!Ethernet}
\index{Gortmaker, Paul}
A complete list of supported boards is available in
the Ethernet HOWTOs posted monthly to \ngrp{comp.os.linux.announce}
by Paul Gortmaker.\footnote{
  Paul can be reached at \email{gpg109@rsphysse.anu.edu.au}.
}


Here's a list of the more widely-known boards supported by \linux. The
actual list in the HOWTO is about three times longer. However, even if
you find your board in this list, check the HOWTO first; there are
sometimes important details about operating these cards. A case in point
is the case of some DMA-based Ethernet boards that use the same DMA
channel as the Adaptec 1542 SCSI controller by default. Unless you move
either of them to a different DMA channel, you will wind up with the 
Ethernet board writing packet data to arbitrary locations on your hard
disk.


\begin{dispitems}
\ditem[3Com EtherLink]
	Both 3c503 and 3c503/16 are supported, as are 3c507 and 3c509.
	The 3c501 is supported, too, but is too slow to be worth buying.

\ditem[Novell Eagle]
	NE1000 and NE2000, and a variety of clones. NE1500 and NE2100
	are supported, too.

\ditem[Western Digital/SMC]
        WD8003 and WD8013 (same as SMC Elite and SMC Elite Plus)
        are supported, and also the newer SMC Elite~16 Ultra.

\ditem[Hewlett Packard]
        HP 27252, HP 27247B, and HP J2405A.

\ditem[D-Link]
	DE-600 pocket adaptor, DE-100, DE-200, and DE-220-T.
	There's also a patch kit for the DE-650-T, which is a PCMCIA
	card.\footnote{
	 It can be gotten~-- along with other Laptop-related stuff~--
	 from \host{tsx-11.mit.edu} in \file{packages/laptops}.
	}

\ditem[DEC]
	DE200 (32K/64K), DE202, DE100, and DEPCA rev E.

\ditem[Allied Teliesis]
	AT1500 and AT1700.

\end{dispitems}


To use one of these cards with \linux, you may use a precompiled
kernel from one of the major \linux{} distributions. These generally
have drivers for all of them built in. In the long term, 
however, it's better to roll your own kernel and compile in only those
drivers you actually need.


\subsection{Ethernet Autoprobing}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{Ethernet!autoprobing|(}
\index{autoprobing, Ethernet}

At boot time, the Ethernet code will try to locate your board and
determine its type. Cards are probed for at the following addresses and
in the following order:


\medskip
\begin{center}
\begin{tabular}{|l|l|}
\hline
Board		& Addresses probed for				\\
\hline
WD/SMC		& \addr{0x300}, \addr{0x280}, \addr{0x380},
		  \addr{0x240}					\\
SMC 16 Ultra	& \addr{0x300}, \addr{0x280} 			\\
3c501		& \addr{0x280} 					\\
3c503		& \addr{0x300}, \addr{0x310}, \addr{0x330},
		  \addr{0x350}, \addr{0x250},			\\
		& \addr{0x280}, \addr{0x2a0}, \addr{0x2e0} 	\\
NEx000		& \addr{0x300}, \addr{0x280}, \addr{0x320},
		  \addr{0x340}, \addr{0x360} 			\\
HP		& \addr{0x300}, \addr{0x320}, \addr{0x340},
		  \addr{0x280}, \addr{0x2C0},			\\
		& \addr{0x200}, \addr{0x240} 			\\
DEPCA		& \addr{0x300}, \addr{0x320}, \addr{0x340},
		  \addr{0x360} 					\\
\hline
\end{tabular}
\end{center}
\medskip


There are two limitations to the autoprobing code. For one, it may not
recognize all boards properly. This is especially true for some of the
cheaper clones of common boards, but also for some WD80x3 boards. The
second problem is that the kernel will not auto-probe for more than one
board at the moment. This is a feature, because it is assumed you want
to have control about which board is assigned which interface.


If you are using more than one board, or if the autoprobe should fail to
detect your board, you have to tell the kernel explicitly about the
card's base address and name.


\index{configuring!Ethernet}
\index{manual configuration (Ethernet)}
\index{Space.c@\file{Space.c}}
\index{autoprobing fails}
\index{lilo@\prog{lilo}}
In Net-3, you have can use two different schemes to accomplish this.
One way is to change or add information in the
\file{drivers/net/Space.c} file in the kernel source code that
contains all information about drivers. This is recommended only if
you are familiar with the networking code. A much better way is to
provide the kernel with this information at boot time.  If you use
\prog{lilo} to boot your system, you can pass parameters to the kernel
by specifying them through the \keyword{append} option in
\file{lilo.conf}. To inform the kernel about an Ethernet device, you
can pass the following parameter:


\begin{tscreen}
 ether=\var{irq},\var{base\_addr},\var{param1},\var{param2},\var{name}
\end{tscreen}


The first four parameters are numerical, while the last is the device
name. All numerical values are optional; if they are omitted or set
to zero, the kernel will try to detect the value by probing for it, or
use a default value.


\index{auto-IRQ}
\index{IRQ}
The first parameter sets the IRQ assigned to the device. By default,
the kernel will try to auto-detect the device's IRQ channel. The
3c503 driver has a special feature that selects a free IRQ from the
list 5, 9, 3, 4, and configures the board to use this line.


The \var{base\_addr} parameter gives the I/O base address of the board;
a value of zero tells the kernel to probe the addresses listed above.


The remaining two parameters may be used differently by different
drivers. For shared-memory boards such as the WD80x3, they specify
start and end addresses of the shared memory area. Other cards commonly
use \var{param1} to set the level of debugging information that is
being displayed. Values of 1 through 7 denote increasing levels of
verbosity, while 8 turns them off altogether; 0 denotes the default.
The 3c503 driver uses \var{param2} to select the internal transceiver
(default) or an external transceiver (a value of 1). The former uses
the board's BNC connector; the latter uses its AUI port.


If you have two Ethernet boards, you can have \linux{} autodetect one
board, and pass the second board's parameters with \prog{lilo}.
However, you must make sure the driver doesn't accidentally find the
second board first, else the other one won't be registered at all. You
do this by passing \prog{lilo} a \option{reserve} option, which
explicitly tells the kernel to avoid probing the I/O space taken up by
the second board.


For instance, to make \linux{} install a second Ethernet board at
\addr{0x300} as \file{eth1}, you would pass the following parameters
to the kernel:


\begin{tscreen}
 reserve=\addr{0x300},32 ether=0,\addr{0x300},eth1
\end{tscreen}


The \keyword{reserve} option makes sure no driver accesses the board's
I/O space when probing for some device. You may also use the kernel
parameters to override autoprobing for \file{eth0}:


\begin{tscreen}
 reserve=\addr{0x340},32 ether=0,\addr{0x340},eth0
\end{tscreen}


To turn off autoprobing altogether, you can specify a \var{base\_addr}
argument of -1:


\begin{tscreen}
 ether=0,-1,eth0
\end{tscreen}

\index{Ethernet!autoprobing|)}
\index{configuring!Ethernet|)}


\section{The PLIP Driver}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{hardware.drivers.plip}
\index{configuring!PLIP}
\index{IP!parallel line|see {PLIP}}
\index{parallel port!IP}
\index{driver!PLIP}
\index{PLIP}

PLIP stands for \emph{Parallel Line IP} and is a cheap way to
network when you want to connect only two machines. It uses a
parallel port and a special cable, achieving speeds of 10kBps to
20kBps.


PLIP was originally developed by Crynwr, Inc.  Its design is rather
ingenuous (or, if you prefer, hackish): for a long time, the parallel
ports on PCs used to be only uni-directional printer ports; that is,
the eight data lines could only be used to send from the PC to the
peripheral device, but not the other way round. PLIP works around
this by using the port's five status line for input, which limits it
to transferring all data as nibbles (half bytes) only. This mode of
operation is called mode zero PLIP.  Today, these uni-directional
ports don't seem to be used much anymore. Therefore, there is also a
PLIP extension called mode 1 that uses the full 8~bit interface.


Currently, \linux{} only supports mode 0.  Unlike earlier versions of the
PLIP code, it now attempts to be compatible with the PLIP implementations
from Crynwr, as well as the PLIP driver in NCSA \prog{telnet}.\footnote{
  NCSA \prog{telnet} is a popular program for DOS that runs TCP/IP
  over Ethernet or PLIP, and supports \prog{telnet} and FTP.
} To connect two machines using PLIP, you need a special cable sold at
some shops as ``Null Printer'' or ``Turbo Laplink'' cable. You can,
however, make one yourself fairly easily. Appendix~\ref{appendix.plip}
shows you how.


\index{Yutaka, Niibe}
The PLIP driver for \linux{} is the work of almost countless persons.
It is currently maintained by Niibe Yutaka.  If compiled into the
kernel, it sets up a network interface for each of the possible
printer ports, with \file{plip0} corresponding to parallel port
\file{lp0}, \file{plip1} corresponding to \file{lp1}, etc.  The
mapping of interface to ports is currently this:


\medskip
\begin{center}
\begin{tabular}{|l|l|l|}
\hline
Interface	& I/O Port	& IRQ		\\
\hline
\file{plip0}	& \addr{0x3BC} 	& 7		\\
\file{plip1}	& \addr{0x378} 	& 7		\\
\file{plip2}	& \addr{0x278} 	& 5		\\
\hline
\end{tabular}
\end{center}
\medskip


\index{configuring!PLIP}
\index{manual configuration (PLIP)}
\index{Space.c@\file{Space.c}}
If you have configured your printer port in a different way, you
have to change these values in \file{drivers/net/Space.c} in
the \linux{} kernel source, and build a new kernel.


This mapping does not mean, however, that you cannot use these
parallel ports as usual. They are accessed by the PLIP driver only
when the corresponding interface is configured \keyword{up}.


\section{The SLIP and PPP Drivers}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{hardware.drivers.slip}
\index{driver!SLIP}
\index{driver!PPP}
\index{SLIP}
\index{IP!serial line|see {SLIP}}

SLIP (Serial Line IP), and PPP (Point-to-Point Protocol) are a widely
used protocol for sending IP~packets over a serial link. A number of
institutions offer dialup SLIP and PPP access to machines that are on
the Internet, thus providing IP~connectivity to private persons
(something that's otherwise hardly affordable).


To run SLIP or PPP, no hardware modifications are necessary; you can use
any serial port. Since serial port configuration is not specific to
TCP/IP networking, a separate chapter has been devoted to this.  Please
refer to chapter~\ref{serial} for more information.


% \section{Using \prog{ifsetup}}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \namedlabel{hardware.ifsetup}{Using \prog{ifsetup}}
% \index{ifsetup@\prog{ifsetup}}
% \index{DDI}
% 
% With DDI, you can easily configure a device that hasn't been
% recognized by kernel autoprobing, or modify a device's configuration,
% by using \prog{ifsetup}.\footnote{
%  \prog{ifsetup} will probably be renamed to \prog{ddicfg} some day.
% }.  For example, to tell DDI that your NE2000 board has a base I/O
% address of \addr{0x280}, and an IRQ of 9, you can set it up by
% typing:
% 
% 
% \begin{tscreen}
%  \# ifsetup /dev/net/ne0 io \addr{0x280} irq 9
% \end{tscreen}
% 
% 
% Of course, the device driver will check if there is any such board at
% the address you specified, and complain if there isn't. If it succeeds,
% the device is assigned an interface.
% 
% 
% The device files you can use with DDI reside in the \file{/dev/net}
% directory.  Their names refer to the driver (here: \file{ne} for the
% Novell Ethernet driver), and a unit number. They have nothing to do with
% the interface names used by the networking code, like \file{eth0}.
% 
% 
% The device names currently used are \file{ne} for the Novell Ethernet
% driver, \file{wd} for the Western Digital/SMC driver, \file{el} for the
% 3Com EtherLink driver, \file{hp} for the (you guessed it) HP driver,
% \file{depca} for the DEPCA driver, \file{dlink} for the DE 600 pocket
% adaptor driver.  Each is, of course, followed by a unit number.
% 
% 
% \prog{ifsetup} understands the following options:
% 
% \begin{dispitems}
% \ditem[\option{io}]
% 	This option sets the base I/O address of the device. Giving
% 	a value of \keyword{clear} means to remove the device.
% 
% \ditem[\option{irq}]
% 	This sets the device's IRQ to the specified value. A keyword
% 	or \option{auto} will make it attempt to auto-detect the IRQ.
% 	The 3c503 driver will even attempt to allocate a free IRQ
% 	line out of 5, 9, 3, 4, and configure the card to use this
% 	line.
% 
% \ditem[\option{maddr} and \option{msize}]
% 	For shared-memory boards such as the WD80x3, \option{maddr} and
% 	\option{msize} can be used to specify start and end address of
% 	the shared memory area.
% 
% \ditem[\option{dma}]
% 	This assigns the device the DMA channel specified.
% 
% \ditem[\option{aux}]
% 	This is a jack-of-all-trades option. It is currently used by the
% 	3Com driver to select the internal transceiver (default) or an
% 	external transceiver (a value of 1). The former uses the board's
% 	BNC connector; the latter uses its AUI port.
% 
% \end{dispitems}
% 
% 
% When invoked with only a device name, \prog{ifsetup} will display
% that interface's configuration, or an error message if no such device
% is configured.

\index{configuring!network hardware|)}
\index{hardware!networking|)}
